Mir hat dieser Artikel ĂŒber das Denken zweiter Ordnung sehr gut gefallen.
Er erklĂ€rt am Beispiel von 'Chestertons-Fence', warum es wichtig ist, vor Ănderungen an Systemen das Denken zweiter Ordnung einzusetzen. Er nutzt dazu die Methapher eines Zauns ĂŒber eine StraĂe. Diesen sollte man nicht einfach wegrĂ€umen, nur weil er nervt. Warum? Weil die Menschen die ihn gebaut haben hatten damit Aufwand, den Sie nicht einfach nur so zum SpaĂ investiert haben. Deren GrĂŒnde muss man verstehen um zu sehen ob der Zaun tatsĂ€chich weg kann, oder nach wie vor nötig ist.
Angenommen hinter dem Zaun befindet sich ein StraĂenabschnitt, der mit Minen verseucht ist. Leider ist dies in der Ukraine ja ein hĂ€ufiges Problem. Der Zaun sollte erst entfernt werden, wenn die Minen gerĂ€umt sind, um TodesfĂ€lle und Verletzungen zu vermeiden. Die Toten und Verletzten sind hier der Effekt zweiter Ordnung.
Denken zweiter Ordnung heiĂt also nicht nur zu hinterfragen, warum etwas so ist, wie es ist, sondern auch zu verstehen, warum die Menschen, die es geschaffen haben (in unserem Fall meistens Code), es auf diese Weise gebaut haben. Bevor ich Ănderungen vornehme, sollte ich mir Zeit nehmen, um die GrĂŒnde fĂŒr die ursprĂŒngliche Gestaltung zu verstehen, da unbedachte Ănderungen unerwĂŒnschte Effekte haben werden.
So zu denken finde ich nicht leicht. Oft misslingt es mir. Aber es ist fĂŒr mich ein Ziel.
Was heiĂt das fĂŒr uns Entwickler?
Besonders bei der Frage: Wieso sind unsere Systeme so wie sie sind? Ist das fĂŒr mich super relevant. Aber auch immer wenn ich Programmiere. Wenn ich einen Zaun aufstelle, also z.B. etwas komplizierter mache als es sein könnte, dann schreibe ich einen Kommentar wieso ich mich gegen die einfachere Lösung entschieden habe, damit die nach mir kommenden verstehen ob meine - fĂŒr Sie - ĂŒberkomplizierte Lösung noch nötig ist. Wenn ich eine weiter reichende Entscheidung fĂ€lle, dann Dokumentiere ich diese gerne mit eineme Architektural Decision Record (ADR) der enthĂ€llt aus welchen GrĂŒnden wir uns so entschieden haben. Wenn ich eine Story schreibe, dann muss da nicht nur das Feature drauf, sondern eben auch der Grund dafĂŒr, damit ich oder andere spĂ€ter nachvollzieen können, wieso dieses Feature existiert, oder eben wieso es nicht mehr nötig ist. Idealerweise wĂŒrde ich auch gerne vom Code ĂŒber die Commits zur Story zurĂŒck kommen - aber das gelingt mir bisher regelmĂ€Ăig nicht.
Fazit
Viele der Praktiken, die wir in der Softwareentwicklung als Standards ansehen, dienen eigentlich dazu, das Denken zweiter Ordnung zu erleichtern â ein wichtiger Zusammenhang, der oft unerwĂ€hnt bleibt, mir aber zunehmend klarer wird.
Ganz besonders wichtig ist mir aber der Respekt, im Zweifel sollte ich erst einmal annehmen das der andere sich etwas dabei gedacht hat. Bevor ich das nicht verstehe sollte ich nicht die Axt ansetzen.